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A declarative approach to program- 
ming involves providing a transaction en- 
gine and a repository. The transaction en- 
gine controls the behavior of an application 
by routing messages between a pre-defined 
group of work steps. The repository in- 
cludes a declaration space within which 
components are defined as well as the re- 
lationship between the components. An ad- 
ministrator includes an Integrated Develop- 
ment Environment (IDE) editor for allowing 
developers to access and modify portions of 
the repository. In the preferred embodiment, 
developers are allowed to define attributes of 
data elements, define relationships between 
the data elements, and to organize data ele- 
ments into messages through the repository. Furthermore, developers are able to define the logical-to-physical mapping in the repository, 
such as by defining message stores. An application is defined by a workflow comprised of a number of worksteps interconnected to each 
other. The workflow and the worksteps are also defined within the repository. Interfaces developed with the repository and transaction 
engine can be dynamically changed based on user, security, language, and locale. The repository and transaction engine also enable the 
inheritance of values and provides message inheritance, language inheritance, sibling inheritance, container inheritance, and attribute inher- 
itance. 
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METHODS AND SYSTEMS FOR DEVELOPING 

APPLICATIONS AND FOR INTERFACING WITH USERS 

RELATED APPLICATIONS 
5 This patent application claims priority to, and incorporates herein by reference, co- 

pending provisional patent application Serial No. 60/123,976 filed on March 1 1, 1999. Also, 
this application is related to co-pending provisional patent application Serial No. 60/123,977, 
filed on March 11, 1999, co-pending provisional patent application Serial No. 60/123,886, 
co-pending utility patent application filed on March 10, 2000, entitled "Methods and 
10 Systems for Performing Workflow" and co-pending utility patent application filed on March 
10, 2000, entitled "Methods and Systems for Managing Financial Accounts." 

FIELD OF THE INVENTION 
The present invention relates generally to methods and systems for developing 
1 5 applications and, more particularly, to systems and methods for providing declarative 
programming techniques. According to another aspect, the invention relates generally to 
systems and methods for interfacing with a user and, more particularly, to systems and 
methods for selectively displaying information to a user. 

20 BACKGROUND OF THE INVENTION 

Many companies developed or purchased computer systems years ago, if not decades 

ago, to manage important data and information. The majority of these legacy systems were 

developed on mainframes and consequently use mainframe storage technologies, such as 

IBM Information Management System (IMS), Virtual Sequential Access Method (VSAM), 
25 or DB2 relational database management system (RDBMS). Financial institutions, for 

example, have mainframe applications that track individual customer accounts and over the 

years have amassed large databases to contain all this information. 

Companies cannot readily change or update these legacy systems since they run 

mission-critical applications. While the migration of these applications to systems having 
30 more advanced software and hardware is possible, migration would expose the companies to 

the risk of a failed conversion. Even though the probability of the risk may be small, a failed 
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conversion can disable one of the mission-critical applications and would be disastrous for a 
company. It is therefore not surprising that many companies are content to rely on their 
legacy systems and are cautious in making any update to these systems. 

One disadvantage of many legacy computer systems is that by today's standards, they 
have a fairly limited user interface. To enter data, the user is required to place the data at a 
certain location on the screen. Similarly, the legacy systems require data output from the 
system to be sent to a specific location on the screen. For instance, with this type of 
interface, the name of a cardholder must always be displayed in one location of the screen, 
the account number in a second location, the remaining balance in a third location, etc. With 
these legacy systems, ensuring that particular information is displayed in a consistent manner 
on all screens without special programming efforts is a challenge. This type of interface 
places a large constraint on how a user interfaces to the legacy systems. 

Additionally, this interface is not efficient in the way that a user interacts with the 
systems. This type of interface does not optimally convey information to the user since it 
typically presents a large amount of information to the viewer in multiple fields spread 
throughout the screen. The user also cannot easily enter data since the data must be entered 
at specific locations on the screen. Further, this type of interface, by itself, is not compatible 
with displays that allow for dynamic alteration of displays, such as Windows®, and is 
therefore not user-friendly. 

Other limitations exist with the legacy systems and even typical state-of-the-art 
displays that allow for dynamic alteration of displays, such as Windows®-based 
applications. One of these limitations is the positioning of elements in the display are 
defined at fixed positions within a display. Because elements are defined in an absolute 
manner, developing and maintaining consistent screens becomes very difficult. 

Instead of completely migrating a legacy system to a new platform, updates may be 
made to a legacy system to improve its performance. With regard to the user interface, such 
updates may involve implementing terminal emulation to provide a more robust interface. 
In general, terminal emulation involves maintaining the legacy system on the mainframe but 
providing a client application that emulates the terminal protocols, such as by reading data 
from and sending data to specific locations on the screen. Screen scraping is a relatively 
easy and inexpensive way that allows users to interact with a legacy system. 
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The existing methods of terminal emulation, however, are not without their 
shortcomings. Terminal emulation, for example, typically separates the front end client 
application from the mainframe programs and data files and, as a result, slows down 
communications and degrades the performance of the overall system. Although screen 
5 scraping is inexpensive and easy, screen scraping still requires the user to move between 
multiple screens to perform standard functions. Thus, a need still exists for a better way of 
interacting with legacy systems. 

Many interfaces to computer systems, not just those having legacy systems, are rather 
inflexible in the way that information is displayed. For example, a common way to display 

10 data is to place the name of a parameter, such as customer account number, next to a field 
containing the actual data, such as the actual account number. While displaying data in 
fields is convenient, a challenge occurs when certain data cannot be displayed because of 
security concerns. For example, different users of a system often have different levels of 
access to the data and some users may not be permitted to see or modify all parameters. The 

15 values for these sensitive parameters must therefore be omitted when displaying data to those 
users who do not have proper authorization. To provide this security, computer systems 
must have another layer of complexity in the software to ensure that each user has the proper 
authorization to view the data. This complexity places an added burden on the development, 
maintenance, and operation of the system. 

20 When data is not displayed because of security reasons, a typical computer system 

maintains the same template for the display but conceals the underlying data for a certain 
parameter. For instance, when a user is not authorized to view a customer's Personal 
Identification Number (PIN), a computer system may display the title "PIN" but gray out or 
otherwise conceal the customer's actual number for the PIN. This display of the title and 

25 field of a concealed parameter is undesirable for several reasons. For one, placing 

unnecessary information on the display screen wastes the valuable real estate of the screen 
and is somewhat unsightly. Secondly, the user would likely prefer not to see anything about 
a field that he or she does not have proper authorization to view. The user, for instance, may 
not realize that he or she was hot granted access to the data and question why that data is not 

30 shown. The user may also be resentful that he or she is not entrusted to access the data. 
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Another way in which computer systems are inflexible is that the interfaces cannot be 
easily converted to accommodate different languages. For example, a first version of an 
interface may have the display optimized for one language and many changes may be 
necessary if a second language is desired. For instance, the translation of text from one 
5 language to another may force changes in the spacing allotted for titles of fields, the spacing 
within each field, the positioning of adjacent fields, as well as other aspects of the interface. 
These changes are usually implemented by coding an entirely different version of the 
application or, if a version is multi-lingual, by coding different sets of displays for the 
different languages. Thus, a significant amount of work is needed to provide interfaces to an 

1 0 application in another language. 

In addition to problems with developing and using computer interfaces, many 
programs are confined to only a certain sized systems. For instance, some programs may 
only be capable of accommodating a certain number of users or may be limited in the 
amount of data that may be processed. While these systems may meet the initial needs of a 

15 company, the systems may soon become inadequate after a company grows and has demands 
that exceed the capability of the system. At that time, the company is faced with the 
dilemma of either upgrading to the next sized system or implementing an entirely new 
system. In either way, the cost and disruption to a company can be substantial. 

These examples of the challenges in developing and making interfaces to computer 

20 systems and scaleable systems point to some underlying difficulties inherent in developing 
all software. Programming has traditionally involved writing code to tell a computer "how" 
to perform a task. Each task must be "described" to the computer as a combination of 
instructions from a finite pre-defined instruction set. A programmer must therefore 
explicitly instruct the computer how to perform a task every time that task is to be 

25 accomplished. Many programs therefore contain enormous amounts of code that require a 
considerable commitment of company resources. 

Company resources must not only be devoted when creating new applications but, 
perhaps more importantly, when changes are being made to those applications. It has been 
estimated that approximately 10% of the effort in an application is exerted in creating the 

30 initial version and the remaining 90% is exerted in customizing the application for a 

customer or in continually updating the application. One reason that such a large percentage 
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of a company's resources must be devoted to customizing and updating an application is that 
no two customers are truly alike. One customer may operate on a different platform 
whereby changes to the code is often necessary to run on that operating system. Other 
changes may be needed since customers often use different databases, such as SQL, VSAM, 
5 or DB2. Some customization may also be needed to add functionality to address a 

customer's unique needs. Furthermore, updating will undoubtedly occur because of bugs 
and because of updates in related applications, such as when a new version of an operating 
system is released. 

The enormous size of many programs renders it difficult to make the desired changes 

10 to the code. As mentioned above, procedural programs contain the same set of instructions 
for performing a task each time that the task needs to be executed. A single change to just 
one task, consequently, can easily translate into numerous revisions to the code. The 
millennium bug, also known as the Y2K bug, illustrates how a conceptually simple change 
in the representation of the year can be so difficult to change. Programs that contain the 

15 millennium bug were coded, often in COBOL, to represent the year with just the last two 
numbers of the year, such as "99" for the year 1999. These programs, however, are unable 
to differentiate between a date in the 1900's with one on or after the year 2000. While 
changing the representation of the year from a two digit number to four digits is simple to 
understand, the process of revising a program can be quite complex and burdensome. 

20 Programs will almost invariably contain multiple lines of code reciting the year with some 
programs containing thousands of such lines. To make this simple change, efforts must first 
be directed toward identifying all lines that contain the year followed by efforts to revise 
each of those lines. These efforts place a tremendous cost both in time, money, and lost 
opportunities, on the vendors and/or on the end-users of the programs. As should be 

25 apparent from the difficulty encountered with the millennium bug, other changes to 
programs can deplete an equal amount, if not more, of a company's resources. 

Advances in programming techniques and languages have alleviated to some degree 
the difficulties in developing and maintaining applications. For example, in contrast to 
earlier procedural programming techniques such as COBOL, object-oriented programs 

30 reduce the burden on programmers through the concepts of abstraction, polymorphism, 

inheritance, and encapsulation. In general, programming with an object-oriented language 
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involves identifying the problem to be solved, identifying objects needed for the solution, 
identifying messages to be sent to the objects, and creating a sequence of interactions among 
the objects to solve the problem. 

A significant feature of object-oriented programming is that the objects can be reused 
and can form the foundation for other applications. Class libraries that are available on the 
market allow a great deal of abstraction and reduce the amount of code that must be written. 
Studies have demonstrated that programmers not having access to those classes spend a 
great deal more time in writing a lot more code than programmers who rely on those classes. 

The classes that are currently available are generally very low-level classes and cover 
a broad range of horizontal applications. While the classes do reduce the amount of 
programming necessary, a substantial amount of work is involved in building a set of 
application-oriented classes on top of that foundation. Successful projects therefore still end 
up spending a great deal of time developing elaborate and appropriate classes, which can 
play many roles in building a particular application. 

Despite the use of object-oriented programming and classes, applications still require 
a considerable amount of code that must be written, debugged, and updated. One reason for 
the heavy reliance on code is that there is a tremendous need in the marketplace for 
customization of applications. Many of the earlier object-oriented programs are not very 
configurable. After the object-oriented analysis has been performed and the classes are built 
and defined, the programs are still characterized by having behaviors hard-coded into the 
objects. As a result, whenever any change is needed, such as in a behavior or attribute, the 
change is implemented in essentially the same way that changes have been made for 
decades, which is by accessing the source code and making the change. Although object- 
oriented programming techniques have provided for some abstraction, applications are still 
unable to rely upon higher levels of abstraction and, as a result, many changes are still hard- 
coded into the class definitions. 

Another reason why object-oriented applications are still heavily dependent upon 
large lines of code is that the applications have redundancies spread throughout the coding. 
For example, a payment processing system that is used to manage credit card accounts may 
have a class defined for Transactions, a class for Accounts, and a class for Cards. The 
Transaction class would have a definition for Account Number, the class for Accounts would 
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also include a definition for Account Number, and the Card class would also have a 
definition for Account Number. The program is therefore redundant because it contains 
these multiple definitions for Account Number. 

Object-oriented programming is still heavily dependent upon hard-coding in other 
5 ways as well. For example, a table having a collection of data values can be represented in 
the program in various ways depending upon a method selected for implementing it. A very 
small table may be represented by enumeration statements in C++ or level 88 's in COBOL, a 
larger table with a table of constants compiled into the program, an even larger table might 
be out in another file, and yet an even larger table might be in a database table. Thus, 

1 0 depending upon the selected method, the syntax of the program would be markedly different. 
Each place that a table is referenced, the particular syntax for that table appears. Thus, the 
application contains multiple references to the same table. The need to place the table syntax 
throughout the program not only is a burden during the development of the application but 
also renders it difficult to make any changes to the table. To make a change, such as to how 

1 5 data is stored, the program must be changed every place where that table is referenced. 
Traditional object-oriented programming techniques therefore still often require an 
overabundance of code. 

In addition to being redundant, object-oriented programs are limited in the extent that 
programs are designed and implemented on a logical level. For example, when accessing 

20 databases, object-oriented programming does permit one to design at a logical level but, 

when implementing the design, the programs contains code, such as SQL statements, for the 
physical representation of the database. Consequently, during the logical-to-physical 
mapping, if a change is desired to either normalize or de-normalize some tables, then all of 
the select statements that refer to those tables have to be changed to represent the physical 

25 representation of the table. As another example, at the logical level, a join may exist 

between two tables with the join being on a particular field. On the other hand, when writing 
the code, there is no easy way of expressing that to the database other than by repeatedly 
restating the fact of the join, which fields are used, and every single statement that refers to 
the two tables that are joined. As a further example, programs often contain stored 

30 procedures in order to use databases in an efficient way. Every stored procedure language, 
however, is different whereby a greater reliance on stored procedures renders the program 
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less database independent. A need therefore exists for a way of expressing database 
requirements at a logical level and having the physical mapping be more automatic. 

Existing object-oriented programming techniques therefore still have many 
limitations. These techniques, for instance, require an extensive amount of code to be created 
5 during the development of an application and also during any revision to the application. 
One reason for the large size of many object-oriented programs is that the programs contain 
redundant lines of code and have behavior hard-coded. Because the cost of developing an 
application can be proportional to the number of lines of code, development of an 
application can become extremely expensive. The expense is not limited to just the initial 
10 development since programs routinely need to be revised. A revision to the program, even a 
change that is simple at a logical level, requires rewriting and debugging code and is not 
easily or inexpensively implemented. A need therefore exists for improved programming 
techniques. 

15 SUMMARY OF THE INVENTION 

The present invention addresses the problems described above by providing systems 
and methods that implement declarative programming techniques. According to one aspect, 
the invention includes a transaction engine that controls an overall behavior of a system and 
a repository that has a declaration space containing definitions and relationships of the 

20 various components forming an application. A component that forms a building block for an 
application is a data element. Each data element is defined by a set of attributes that may be 
inherited or derived from other data elements and plural data elements may be combined into 
a group. A message type is an abstract representation of a collection of data elements and 
may, for instance, define the relationships between data elements. A message store defines 

25 the logical-to-physical mapping such as by specifying that a data file is a VSAM file, DB2 
file, or other type of file. The repository also includes a definition of a workflow for an 
application. A workflow comprises a set of worksteps linked to each other with connectors. 
The transaction engine routes the messages between the worksteps according to the defined 
workflow. 

30 With the declarative approach to programming according to the invention, 

applications are developed by defining within the repository the various components and 
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their relationships to each other. Applications can therefore be developed and modified by 
altering the database without requiring the creation of any code. The ability to modify 
programs without writing code presents a number of advantages. For one, many changes to 
a program can be implemented without any recompiling and with nominal testing. Also, 
5 changes can be easily performed by the end-user, which may only have a basic 
understanding of program and who is not a programmer. A platform formed of the 
repository and the transaction engine greatly reduces the cost of developing and maintaining 
application. Other benefits and advantages of the declarative programming techniques will 
become apparent from the Detailed Description of the invention. 

10 The repository and transaction engine allow interfaces to be developed that overcome 

many disadvantages of existing interfaces. For instance, interfaces can be dynamically 
altered according to the user, security, language, or locale. With regard to security, when 
data should not be displayed to a particular user, that portion of the display is omitted and the 
screen repositions the remaining data elements. With regard to language, the elements of a 

1 5 screen automatically reposition themselves to accommodate a different language. With 
regard to locale, the interface can be suited for a particular user based on such criteria as 
language, representation of dates, time, decimal points, and currency. The users may be 
grouped together and the passwords, security, locale, and language can be set for each user 
or group of users. 

20 Accordingly, an object of the present invention is to provide systems and methods for 

programming that implement declarative programming. 

Another object of the present invention is to provide systems and methods for 
programming that reduce the amount of code that must be written in developing applications. 
Another object of the present invention is to provide systems and methods for 
25 programming that allow changes to an application to be made quickly and easily. 

A further object of the present invention is to provide systems and methods for 
programming that reduce the need for redundant code in an application. 

A still further object of the present invention is to provide systems and methods for 
programming that allow a greater degree of abstraction. 
30 Yet another object of the present invention is to provide systems and methods for 

programming that eliminates the need to have multiple definitions within an application. 
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A further object of the present invention is to provide systems and methods for 
developing platform independent applications. 

Another object of the present invention is to provide systems and methods for 
developing scaleable applications. 

A further object of the present invention is to provide systems and methods for 
developing real time applications. 

Another object of the present invention is to provide systems and methods for 
interfacing with legacy systems. 

Yet another object of the present invention is to provide systems and methods for 
interfacing with computers that allow dynamic alteration of displays. 

A still further object of the present invention is to provide systems and methods for 
interfacing that easily accommodates different languages. 

A further object of the present invention is to provide systems and methods for 
interfacing that can be easily created and modified. 

Yet another object of the present invention is to provide development platforms upon 
which applications can be easily developed. 

Another object of the present invention is to provide systems and methods of 
programming that allow additional types of inheritance. 

Yet a further object of the present invention is to provide systems and methods for 
allowing inheritance of data in objects. 

Other objects, features, and advantages of the present invention will become apparent 
with respect to the remainder of this document. 

BRIEF DESCRIPTION OF THE DRAWINGS 
The accompanying drawings, which are incorporated in and form a part of the 
specification, illustrate preferred embodiments of the present invention and, together with 
the description, disclose the principles of the invention. In the drawings: 

Figure 1 is a block diagram of a system according to a preferred embodiment of the 
invention; 

Figure 2 is a diagram of interrelationships between design components forming pari 
of the invention; 
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Figure 3(A) is an example of an object tab for a component forming part of the 
invention and Figure 3(B) illustrates a drag and drop feature; 

Figure 4 is an example of assigned permission levels to a component; 

Figure 5 is an example of a data tab for a user component; 

Figures 6(A) to 6(1) are examples of data, message kind, database field, message 
field, GUI, GUI2, label, bar, and help tabs, respectively for a data element component; 

Figure 7 is an example of a data tab for an expression component; 

Figure 8 is an example of a data tab for a restriction component; 

Figures 9(A), 9(B), and 9(C) are examples of data, reference, and label tabs, 
respectively, for a message type component; 

Figure 10(A) is an example of a data tab for a message store component and Figures 
10(B) to 10(G) are examples of a type tab for a message store component illustrating 
different storage types; 

Figures 1 1(A) to 1 1(D) are examples of data, stored procedure, result, and label tabs 
for a query set component; 

Figure 12 is an example of query node tree; 

Figure 13 is an example of a data tab for a query node component; 

Figure 14 is a diagram illustrating a join between two database tables; 

Figure 15 is an example of a data tab for a join component; 

Figure 16 is a diagram of a sample workflow having three worksteps; 

Figures 17(A) and 17(B) are examples of data and label tabs, respectively, for a 
workstep component: 

Figure 18 is a diagram of a sample workflow having worksteps and category 
components; 

Figures 19(A) and 19(B) are examples of a data tab and more tab, respectively, for a 
category component. ■ .. 

Figure 20 is a diagram of a workflow having worksteps, category components, and 
connectors; 

Figure 21 is an example of a data tab for a connector component; 
Figures 22(A) and 22(B) are examples of data and wizard tabs, respectively, for a 
workflow component; 
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Figures 23(A) and 23(B) are examples of data and label tabs, respectively, for a 
language component; 

Figure 24 is an example of a data tab for a locale component; 

Figure 25(A) is a diagram of an attribute inheritance tree and Figure 25(B) is a 
diagram depicting an application of container inheritance; 

Figure 26 is a view from an editor illustrating language inheritance; 

Figure 27 contains tables illustrating message inheritance; 

Figure 28 is an example of a sample panel having data elements and groups of data 
elements; 

Figure 29 is a table illustrating the positioning of data elements in a Group 1 
container in Figure 28; 

Figure 30 is a table illustrating the positioning of the components and groups of 
components in Figure 28; 

Figures 3 1 (A) to 3 1 (C) depict the development of a test panel having various 
components and groups of components; 

Figure 32 is an example of an interface built using a development platform according 
to the invention; 

Figure 33 is a representation of the components and groups of components forming 
the interface shown in Figure 32; ^ 

Figure 34 is a representation of one of the groups of elements listed in the container 
of Figure 33 along with the individual data elements forming that group; 

Figure 35 illustrates the definition of one data element component and its positioning 
relative to a second component in a vertical direction; 

Figure 36 illustrates the definition of one data element component and its positioning 
relative to a second component in a horizontal direction; 

Figure 37 is a representation of a message store component and the various storage 
types available for selection; 

Figures 38(A) and 38(B) are partial views of an interface that the ability of the 
interfaces to dynamically adjust based on user security; and 

Figures 39(A) and 39(B) are partial views of interfaces that illustrate the ability of the 
interfaces to dynamically adjust based upon user language. 
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DETAILED DESCRIPTION 
Reference will now be made in detail to preferred embodiments of the invention, non- 
limiting examples of which are illustrated in the accompanying drawings. 

5 

L Overview 

According to one aspect, the invention is directed to systems and methods 
implementing declarative programming. In a preferred embodiment shown in Figure 1, a 
system includes a transaction engine and a repository. The transaction engine in general 

10 governs the basic behaviors of the system and coordinates work flow and the repository is a 
declaration space for storing object definitions. The system is basically a two-layer 
architecture in which the transaction engine is the lower layer and objects, data tables, and 
user functions defined within the repository form the upper layer. 

As will be described in more detail below, systems and methods according to the 

1 5 invention overcome many of the disadvantages of existing programming techniques. For 
instance, applications can be developed without writing any code but instead by defining 
attributes within the repository. The development time and cost is therefore substantially 
reduced. Furthermore, changes can be made to an application by changing the definitions 
within the repository, thereby avoiding any need to create or to debug any code. Because 

20 changes to a program are almost inevitable, the invention significantly reduces the cost 

involved in updating and customizing applications. The invention also permits applications 
to be truly platform independent and scaleable. Additionally, the systems and methods are 
completely priority-based in real time to ensure that time-based activities are properly 
handled. Other advantages and features of the invention will become apparent from the 

25 description below. 

According to another aspect, systems and methods for interfacing with a computer 
system overcome some of the disadvantages of existing interfaces. For instance, interfaces 
according to the invention allow the dynamic resizing and repositioning of displays based on 
such things as security, language, locality, and user. The interface is platform independent 

30 and can be developed and modified easily. Additional advantages and features of systems 
and methods for interfacing are described in more detail below. 
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II. Architecture 

A. Transaction Engine 

In the preferred embodiment, the transaction engine is formed from a set of highly 
generalized C++ classes. As discussed above, the transaction engine provides the basic 
behaviors for a system and has a core engine that distributes work among various objects and 
manages their relationships. The core engine is a set of code that moves messages from 
sources through processing modules, also called work steps, to stores and also moves 
messages from stores through processing modules to sinks. With the preferred system, most 
work is represented by messages that spend time in the message stores, some of which are 
queues. The work may be performed in interactive way, which requires some interaction 
with a user, or in a non-interactive way. For non-interactive, the core engine determines 
which workstep to execute next based on declared priorities of the worksteps. For 
interactive, the core engine waits for user input before proceeding to the next workstep. 

B. Repository 

In the preferred embodiment, the repository is a persistent collection of object 
definitions organized into component dictionaries with these dictionaries collectively 
forming a library. A dictionary is a collection of components of a similar type, such as all 
message stores. With conventional programming techniques, the relationships among 
objects would normally be computed during program execution. In contrast, the repository 
allows these relationships to be defined in the database and also allows a wide variety of 
restrictions and security relationships to be declared. The repository is not limited in the 
types of objects that may be defined and, in the preferred embodiment, includes the 
following components: application, data element, expression, restriction, message type, 
message store, join, query, query node, user, language, locale, work step, and work flow. 

C. Components 

The systems and methods according to the invention provide a set of component type 
definitions in the form of classes. Objects are named instances of component class 
definitions maintained within the repository and are defined by a set of attributes and values. 
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Reuse of object definitions is supported through inheritance of the attribute values. As will 
be described in more detail, component inheritance according to the invention differs from 
the type of inheritance found in conventional object-oriented programming languages. The 
objects support the addition of data members and the overriding of attribute values within 
5 inherited objects. 



D. Attributes 

As described above, the components are defined through their attributes, which is 
also the case for object-oriented programming. One way in which a component according to 

10 the invention differs, however, is that in addition to a set of attributes, the components also 
have values. One advantage of associating values with the components is that reuse of 
attribute values can be accomplished through inheritance. Inheritance is defined through a 
parent-child relationship of the parent's attribute. The inheritance relation is limited to a 
single parent of a similar component type. An attribute maintains information regarding the 

1 5 inherited state. of its value and inherited values reflect changes to corresponding parent 
component attributes. Non-inherited, also called overridden, attributes are unaffected by 
parent component attribute changes. The set of attribute data types are defined by built-in 
C++ types, component references, and component reference collections. The built-in and 
component reference type attributes resolve inheritance by traversing the inheritance tree 

20 during the deployment phase, which is the conversion from a development repository 

schema to an execution repository schema. The attributes state information is analyzed and, 
for inherited attributes, the parent component is checked for its value and this process is 
repeated recursively until a non-inherited value is found. Component reference collection 
type attributes, on the other hand, maintain only the set of component references defined for 

25 the owning component. For example, a parent's collection attribute may have references 
,"A" and "B" and the child's collection attribute has reference "C." The child's collection 
attribute does not contain references to "A" and "B," although they are inherited from the 
parent. This inheritance structure is maintained in the repository. 



30 



E. Administrator 
In general, an Integrated Development Environment (IDE) editor provides tools for 
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interfacing with the repository. The IDE editor provides a user administration tool for 
allowing a developer to define instances of all objects and permits editing of all objects with 
minimal time and effort. The user administration tool preferably provides an entry for each 
object type, such as data element type and message store, and lists all instances of objects 
within their corresponding object type. Each message type that has been defined would 
therefore appear under message type. The user administration tool supports typical list 
operations such as insert, collapse, and drag and drop. When a new instance is inserted, all 
of the basic attribute names automatically appear with it and are ready to be filled in with 
values. The user administration tool provides an interface suitable for adding new 
components or otherwise altering the transaction engine or repository. A localization editor 
tool allows for the editing of language components and language labels for some 
components and a workflow editor tool allows for the editing of workflow. Additional 
explanation and description of the IDE editor is provided below. 

III. Components 

Each of the various components of the invention forming part of a preferred 
embodiment of the invention will be described in further detail below. The invention, 
however, is not limited to these specific components but instead may include variations of 
these components or other components. Even though each component is addressed 
separated a general description of some of the components will nevertheless be provided so 
as to provide a high level overview. 

With reference to Figure 2, the data element forms the basic unit of data in an 
application. Each data element is defined as an independent entity because it comprises 
everything needed for displaying, editing, storing, security and integrity whether in storage, 
in memory or on the screen, and furthermore exhibit inheritance. Data element definitions 
are gathered together into message types. 

Message types are completely independent of methods used to store data, exhibit 
inheritance, and are recursive. Instances of message types are messages, which are kept in 
message stores. Message stores may be implemented in a variety of ways, including but not 
limited to RDBMS tables, text files, indexed files, operating system queues, and buffers. 
The repository also defines relationships and restrictions. The join component 
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encompasses a wide variety of information concerning the relationships between data 
elements and messages. The join component allows fields between tables to be joined and 
allows data elements to be expressed with reference to other data elements. Restrictions 
express all the limitations on possible values of data elements. The restrictions inherit from 
5 each other and are inherited by the objects to which they are attached. The repository also 
defines users which are organized into groups and have security relationships that may 
influence a user's interface. The repository also defines individual worksteps. The 
worksteps are joined together with connectors to define a workflow. The worksteps and 
messages may have priorities assigned to them which influence the order of execution for the 
1 0 messages and worksteps. 

The administrator includes the Integrated Development Environment (IDE) editor for 
providing a graphical user interface for creating, editing, and deleting component definitions. 
With this declarative approach to programming, attribute definitions and other data 
governing the behavior of an application are contained within the repository. Since most 
15 definitions contain references to other components, graphical views provided by the IDE 
editor can be extremely useful in visualizing the interaction of the components. Thus, the 
figures contain many views of interfaces provided by the IDE editor both to explain the IDE 
editor and to explain the components and their relationships to other components. 

20 A. Object 

As discussed above, the IDE editor allows attributes of objects to be defined within 
the repository. Figure 3 is an example of an object tab that allows a developer to specify a 
unique name to the component and to specify any parent to that object. Additional 
information that may be specified for any component includes the author who created the 

25 component, the version level of the component, and a description of the component. 

Furthermore, each object can have a security attribute, which will be described in further 
detail below. The object tab shown in Figure 3(A) is common to all components and each 
type of component will have one or more additional tabs, which will be described in more 
detail with reference to each component. The repository editor preferably automatically 

30 assigns a component name to an object but this name may be modified by the developer. 

A drag and drop feature is preferably used to assign a component object to its parent 
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property. An example of the drag and drop feature is illustrated in Figure 3(B). With the 
repository editor, a previously defined component object may be selected from an object list 
panel and dragged to an appropriate property, such as SampleDataElementl and 
SampleDataElement2. 

B. Security 

As mentioned above, security is another attribute that may be defined for each object. 
The invention preferably provides various levels of security and controls permissions to 
create, read, update, delete, and execute (CRUDE). Figure 4 provides an example of 
assigned permission levels to various users. As shown in this Figure, a group of users 
defined by Admin has permission to create, read, and update the component DE_1 and users 
defined within group UserJ only have permission to read the component. 

C. Users 

As discussed above, each component can have security assigned based on the user or 
group of users. The users, in turn, are defined with reference to a user component. An 
example of a data tab for a user component is shown in Figure 5. As shown in the Figure, a 
user component includes an identification string attribute defining the user, a password string 
attribute defining the password for the user which is used at login, and a user group attribute 
to define whether the component is a single user or a group of users. Additionally, a user 
component includes attributes defining a user's preferred locale and language, languages 
spoken by the user or group of users, and information attributes Infol to Info4 designed to 
hold user-supplied data for security purposes, such as a mother's maiden name of a user. 

D. Data Element 

A description will now be provided with reference to a data element component and a 
data element group component. A data element component is used to define all data for an 
application and contains information relating to both the application and to the user interface. 
The data element group component is a specific type of data element that allows the 
combination of multiple data element components and data element groups into a single 
object. For instance, a data element group can correspond to a physically contiguous 

-18- 



WO 00/54202 PCTAJS00/06388 
grouping of data or to a rectangular area of the display screen. 

An example of a data tab for a data element component is shown in Figure 6(A). A 
data element component includes a data type attribute for defining the internal data type for 
the component and how its value is stored. The data type may be any type, such as but not 
limited to character, boolean, integer, real, alpha, alpha-numeric, numeric, data, type, 
currency, group, bit map, or array. The data element data tab also includes attributes 
allowing the length of the data to be defined, such as the number of bits required by bit map 
and array. The data element component, as described above, may be a group of data 
elements with the various elements in the group being defined within the elements attribute. 
Also included in the data element data tab are attributes for expressions and restrictions, both 
of which will be described in further detail below. In general, the restrictions attribute can 
be used to define restriction objects used to validate data integrity of data elements. 

As shown in Figure 6(B), the data element component is also defined through a data 
element message tab. Through an audit attribute on this tab, an audit can be defined so as to 
be generated any time the field is updated. Figure 6(C) shows an example of a database field 
tab which allows a developer to define attributes on how to store data elements, such as 
within an RDBMS or VS AM message store. An example of a data element message field 
tab is shown in Figure 6(D). Through this tab, a developer can define the external data type 
of the component and the format of the components data within a message type data stream. 
The IDE editor preferably provides a drop-down box containing the possible selections, such 
as but not limited to native, ASCII, EBCDIC, unsigned BCD, signed BCD, or bit field. 

An example of a GUI tab is shown in Figure 6(E). In general, the GUI tab attributes 
allow a developer to define how the data element will be graphically represented on a 
display panel or screen. The view attribute defines the type of control used to view the data 
value of a component. A position attribute defines the location of the component within its 
group if the element forms part of a container or panel. The position attribute preferably 
allows the component to be displayed at a fixed location on this screen, such as top left, top 
right, bottom left, or bottom right, or to display the component relative to another object. A 
panel type attribute defines the type of window used to display the panel. 

An example of a data element GUI2 tab is shown in Figure 6(F). The GUI2 tab 
provides additional attributes for defining aspects of a data element. These attributes include 
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expression attributes for defining how the element is displayed and an actions attribute that 
defines how an application will respond to predefined panel events. 

An example of a data element label tab is shown in Figure 6(G) and includes 
attributes for defining a label for the component. An example of a data element bar tab is 
shown in Figure 6(H) and includes attributes for defining such things as a tool tip, status bar, 
menu bar, and tool bar. An example of a data element help tab is shown in Figure 6(1). The 
help tab allows a developer to define the text that is displayed when a user selects a help 
function. 

E. Expressions and Restrictions 

As discussed above, an expression may form part of the definition of an object. 
Expressions may be used in many places for various purposes, such as to assign and analyze 
data, invoke functions, or define symbolic names. An expression is defined by an expression 
component and is defined preferably using C or C++ read-only syntax. A sample data tab 
for an expression component is shown in Figure 7(A) and defines the value of the data 
element and provides a default value for the data element. Both of these attributes are 
defined with reference to an expression component that would be inserted in those fields. 
Figure 7(B) illustrates an example of an expression edit panel for defining an expression. 
The expression component also includes an attribute for defining the language for the text. 
The language component will be described in further detail below. 

A restriction component is a boolean expression that provides constraints on data 
element values and also integrity tests for message types. Using the drag and drop feature, 
multiple restriction objects can be assigned to the restrictions (RR) property of both data 
elements and message types. An example of a data tab for a restriction component is shown 
in Figure 8. 

F. Message Types and Message Stores 

A message is a mechanism used to input, output, and transfer information throughout 
an application, and a message type component defines a physically contiguous group of data 
items. A message instance is an actual message for a particular message type. In other 
words, if a message type is defined to hold an account number and name as data elements, 
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then a message instance of that message type might hold the values 1234 and John Doe. A 

message instance result set is a special class of a message instance that contains multiple 

message instances. For example, if a message instance contains a single account number and 

name, a message instance result set would contain multiple account numbers and names. 

5 An example of a message type data tab is shown in Figure 9(A). A priority attribute 

is provided on the message type data tab and allows a developer to assign an integer value to 

the message type. The integer value is used by the transaction engine to set an overall 

priority level for processing. In addition to messages, an application component, workflow 

component, and workstep component also have an associated priority attribute used by the 

10 transaction engine in determining priorities of these elements. Also included on the message 
type data tab is an items attribute. The items attribute allows a developer to define the data 
elements and/or data element groups that combine to make up the message type. The 
message type data tab also includes a timed attribute that allows a developer to define a 
timing requirement associated with the message type. Additionally, the user can define an 

1 5 appropriate response if the message type is not completed within the allotted time period. 

An example of a message type reference tab is shown in Figure 9(B). The message 
type reference tab has a restriction attribute that allows a developer to define the restrictions 
used to validate the data integrity of the message type data stream. These restrictions are 
executed by the transaction engine during parsing of the input data stream. An example of a 

20 message type label tab is shown in Figure 9(C). The message type label tab has a group 
label attribute which is an expression that allows a developer to define the label that will 
appear in a group of messages of this message type in an explorer control for the language 
specified. For example, if this message type represents a customer, the attribute may be set 
to "Customers." The message type label tab also includes a single label attribute which is an 

25 expression that allows a developer to define the label that will appear for a single message of 
this message type in an explorer control for the language specified. For example, if this 
message type represents customers, a label such as "Customer: Big Spender' 5 may be 
displayed. While the group label attribute will often be a simple character expression, the 
single label attribute will likely take advantage of the fact that this is in fact an expression 

30 and will combine static text and values that exist in the context. 

In general, a message store defines the type of storage used to maintain a message 
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store component. Each message store component has an associated message type that 
specifies the content and layout of the data written to and read from the message store. Once 
defined, message stores allow the application to input and output data without regard to the 
method used to physically maintain the information. 

An example of a message store data tab is shown in Figure 10(A). The message store 
data tab has a Windows® MsAccess® attribute that allows a developer to define the type of 
access allowed to the message store. The MsAccess® attribute may define various levels, 
such as read only, write only, read/write, or no access. The message store data tab also has 
an MType attribute that allows a developer to define the content and layout of all data 
elements written to and read from this message store and a FileName attribute that allows a 
developer to define the actual name of the file for a non-RDBMS message store or the table 
name for an RDBMS message store. The message store data tab also includes an MSShare 
attribute that allows a developer to define the type of sharing allowed for this message store. 
This attribute may permit various types of sharing, such as compatible share, no sharing, 
read share, read/write share, or write share. A timed attribute is also provided on the 
message store data tab and allows a developer to indicate that timed messages are supported 
by this message store. Another attribute included within the message store data tab is a 
temporality attribute that allows a developer to indicate that the message store supports 
temporal data. In general, temporality allows developers to define the time during which 
specific values for data elements in the message store are valid. Temporality permits 
developers to define conditions that become effective for a specified time interval. Also, 
multiple changes made to the application over a period of time can all be set to become 
effective at the same time. A TemporalTable attribute allows a developer to indicate that a 
separate table exists that controls the temporality feature. 

Message store components also include attributes for defining the storage type. The 
invention supports any type of storage including, but not limited to, DBMS, Flat File, In 
Memory, Queue, Logical, VSAM, HLLAPI and Network. An example of a flat file tab is 
shown in Figure 10(B) and allows a user to define the type of data within the flat file, such as 
ASCII or binary. The flat file type tab also includes an OpenMode attribute that allows a 
user to define the manner in which the file should be opened if it can be written to, includes 
an append option for specifying that the file should be opened in a manner in which any data 
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written to this file is appended to existing data, and a truncate option which indicates that the 
file should be opened in a manner in which any existing data in the file is removed before 
any new data is written to it. An example of a DBMS type tab is shown in Figure 10(C). 
This tab includes a dbName attribute which allows a developer to define the name of the 
5 database on the server, a dbmsType attribute which allows a developer to define the type of 
server, such as a SQL server, and a dbServer attribute that allows a developer to define the 
name of the server containing the database. An example of a VSAM type tab is shown in 
Figure 10(D). By specifying the message store as a VSAM type, applications developed 
with the invention can access VSAM files on a host computer for data storage. 

10 An example of a network type tab is shown in Figure 1 0(E). By specifying the 

storage type as network, a user can define applications that use a network connection for data 
storage. The network storage type tab includes a transport attribute which allows a 
developer to identify the type of connectivity that will be used by this message store. The 
invention supports any type of transport, including but not limited to TCP/IP, NetBios, 

1 5 Lu2.0, Lu6.2, Async, Spex/Ips, Bisync, X.25, Pipe, and File. Other attributes provided on 
this type tab allows a developer to define the protocol, to select raw or extended 
connectivity, to define compression, to define a specific port, to define a host address, and to 
define time out functions. 

An example of a HLLAPI storage type tab is shown in Figure 10(F). This type of 

20 message store, allows a user to define a HLLAPI connection for data storage. This tab 

includes a settle time attribute for allowing a developer to define the amount of time to wait 
for a screen to display before electronically reading or scraping the screen, an HLLAPI time 
out attribute for allowing a developer to define the amount of time to wait for the host to 
respond before returning an error, and an emulator type attribute to indicate the name of the 

25 software package being utilized for HLLAPI. An example of a Disk Storage Location 

(DSL) storage type tab is shown in Figure 10(G). The DSL type tab allows a developer to 
define DSL files and to identify a server for the DSL files. 



G. Queries and Query Nodes 
30 A query set component provides a way of retrieving or deleting data from one or 

more message stores by defining the data elements and any limiting criteria. An example of 
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a query set data tab is shown in Figure 1 1(A). The query set data tab includes a scope 
attribute which allows a developer to define where the results should be placed in the 
context, which will affect when the results are removed. The scope attribute in the preferred 
embodiment includes selections for workstep, transaction, workflow, and application. The 
query set data tab also includes an action attribute which allows a user to define the initial 
action to take when executing a command. Through the action attribute, a developer can 
specify that the initial action should be taken in order to select or retrieve data from a 
message store or the action should be taken so that data defined by the select criteria is 
deleted. The query set data tab also includes a TimeoutAction attribute that allows a 
developer to define the action to be taken if the current transaction reaches a time out. 

An example of a query set stored procedure tab is shown in Figure 1 1(B) and allows a 
developer to identify a pre-defined procedure that executes and returns desired results. The 
query set stored procedure tab also includes an input parameter attribute that allows a user to 
define all input data required by a specific stored procedure in order to execute. 

An example of a query set result tab is shown in Figure 1 1(C). The query set result 
tab includes a SelectCriteria attribute that allows a developer to define an expression that 
identifies a set of results. For instance, the select criteria attribute may be used to select all 
of the accounts for a certain customer, all of the accounts for a currently selected customer in 
a certain context, or all of the accounts that have a balance greater than a certain dollar 
amount. A result attribute allows a developer to define data elements to retrieve. A 
developer is able to select only certain data elements within a message store or to select the 
entire set within the message store. The query set result tab also includes a sort attribute that 
allows a developer to define the sort order of the results to be returned. 

An example of a query set label tab is shown in Figure 1 1(D). The query set label tab 
includes a group label expression attribute that allows a developer to define the label that 
will appear if a group of messages of this message type are displayed in an explorer control 
for the language specified. The query set label tab also includes a single label expression 
attribute which allows a developer to define the label that will appear for a single message of 
this message type in an explorer control for the language specified. 

A query node component provides a way of retrieving data using either a query set or 
a join component. Each query node can also be assigned a position within a tree-like 
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structure of query nodes and is executed in a sequence as defined by the tree. This provides 
the ability to link any combination of query sets and joins in an ordered sequence for 
execution. For example, Figure 12 illustrates a query node structure made up of eight nodes. 
When called by an application, query node 2 QN2 would first execute its query set or join 
5 and retrieve the results and then call both query nodes 5 QN5 and 6 QN6. The data retrieved 
by query node 2 QN2 would be available to both query nodes 5 QN5 and 6 QN6 and could 
be used in the definition of their query set or join. 

An example of a query node data tab is shown in Figure 13. The query node data tab 
includes a query attribute that allows a user to retrieve data as specified in a query set object. 
10 The query node data tab also includes a node child attribute that allows a user to define 
another query node as a child of this node in a tree-like structure, such as the one shown in 
Figure 12. 

H. Join 

15 A join component defines a logical link between two tables and a database. The 

joins, as discussed above, are used by queries to quickly establish a unique row of data that 
will satisfy specific search criteria. For example, Figure 14 illustrates how two database 
tables can be joined by the state code and state fields. Using this logical connection provided 
by the join definition, queries to the database could quickly retrieve the full state name from 

20 the first table for any corresponding state code found in the second table. 

An example of a join data tab is shown in Figure 1 5. The join data tab includes a 
RelType attribute that allows a developer to define the relation type, examples of which are 
for joining database tables, inheritance, and GUI. The join data tab also includes a parent 
cardinality attribute and a child cardinality attribute. The parent cardinality attribute allows 

25 a developer to define the cardinality rules from the parent to the child table and, conversely, 
the child cardinality attributes allows a developer to define the cardinality rules from a child 
to the parent table. These rules, for instance, may include one to none, one to one, or one to 
many. The join data tab also includes an attribute to allow a developer to identify a message 
store as the parent and an attribute for allowing a developer to identify a message store as the 

30 child. Furthermore, the join data tab includes attributes for allowing a developer to define 
parent data elements and child data elements. 
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I. Workflow and Worksteps 

As discussed above, the transaction engine routes messages through worksteps to 
achieve a desired workflow. Each workflow is made up of interconnected units of work 
called worksteps. Each workstep component defines specific units of work required to 
perform the overall function of the workflow. 

A first step in defining a workflow is to create the individual worksteps. Figure 16 
illustrates a diagram of the first step in the formation of a workflow. Figure 16 illustrates 
three types of worksteps: a source workstep, a mapper workstep, and a sink workstep. In 
general, a source workstep inputs data from message stores, a mapper workstep provides 
general data processing, and a sink workstep outputs data to the message stores. 

An example of a workstep data tab is shown in Figure 17(A). The workstep data tab 
includes a step type attribute that allows a developer to define the overall functionality of the 
workstep component. The workstep may be of any type including, but not limited to, a 
mapper, a source, a sink, or an interactive workstep that provides a user interface for 
interactive workflows. The workstep data tab also includes a priority attribute that allows a 
developer to set the relative priority level for processing this step versus other active 
worksteps. The workstep data tab also includes a message store attribute for allowing a 
developer to indicate the message store used as an input for a source-type workstep or as an 
output for a sink-type workstep, a query node attribute for allowing a developer to indicate 
the queries that should be executed when selecting data from a message store, and a panel 
attribute to allow a developer to indicate the panel that should be displayed when processing 
the workstep. 

An example of a workstep label tab is shown in Figure 17(B). The workstep label tab 
includes a display label attribute that allows a user to have multi-lingual worksteps. With 
this attribute, a user can identify the name of a specific supported language or a string 
representation of a label text for a specific language. 

After defining the type of the workstep, the developer next defines category 
components. A category component resides within a workstep and provides a way to accept 
input messages and produce output messages. Category components are terminal points for 
all data transfers between worksteps. Figure 18 illustrates the addition of categories to the 
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worksteps of Figure 16. An output category has been added to the source workstep, both 
input and output categories have been provided to the mapper workstep, and an input 
category has been provided to the sink workstep. In general a category component 
represents a scenario that may lead to a specific workstep or provide an exit from one 
5 workstep to another workstep. 

An example of a category data tab is shown in Figure 19(A). The category data tab 
includes a category type attribute which allows a developer to define the overall 
functionality of the category component, such as an input that accepts input messages or an 
output that produces output messages. A queue attribute provided on the category data tab 

10 allows a developer to reference a message store associated with the category component. An 
example of a category "More" tab is shown in Figure 19(B) and includes an expressions 
attribute that allows a developer to specify expressions to run sequentially to populate the 
context of the current category. The category "More" tab also includes a relationships 
attribute that allows a developer to select data and populate the context of the current 

15 category. 

After defining the worksteps and the categories, the process of defining a workflow 
next involves providing connections between the worksteps. A connector component is 
defined to provide the data path between the output-type category of one workstep with the 
input-type category of another workstep. Figure 20 illustrates a workflow in which the 

20 worksteps and categories shown in Figure 1 8 have been tied together with connectors. As 
shown in this Figure, the output-type category of the source workstep is connected to the 
input-type category of the mapper workstep and the output-type category of the mapper 
workstep is connected to the input-type category of the sink workstep. 

An example of a connector data tab is shown in Figure 2 1 . The connector data tab 

25 includes a StepTo attribute that allows a developer to define the workstep that control is to 
be transferred to when executing this connector and a StepFrom attribute that allows the 
developer to define the workstep that control is transferred from when executing this 
connector. The connector data tab also includes a flow attribute that allows a developer to 
define the workflow to which this connector belongs. The connector data tab also includes 

30 attributes for allowing the developer to define the category that this connector should 

execute in the StepTo workstep and also the category that the connector should execute from 
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in the StepFrom workstep. 

A workflow is therefore created by defining worksteps, categories, and connections 
- between the worksteps. An example of a workflow data tab is shown in Figure 22(A). The 
workflow data tab includes a priority attribute that allows a developer to assign an integer 

5 value, such as between 0 and 255, as the priority value for the workflow. This priority value 
is used to set an overall priority level for processing. The workflow data tab also includes a 
workflow type attribute that allows a developer to specify when the workflow should 
execute, such as at start up when the application starts, at shut down just before an 
application terminates, or at a normal time when the workflow is called. The workflow data 

10 tab also includes a steps attribute that allows a developer to identify all of the workstep 

objects associated with the workflow and a connections attribute that identifies all connector 
objects associated with the workflow. A flow panel attribute allows a developer to specify a 
panel, which is a data element group, that is to be displayed when the workflow is running. 
A champion challenger attribute identifies all champion challenger objects associated with 

1 5 the workflow. An example of a workflow wizard tab is shown in Figure 22(B). The wizard 
tab allows a developer to add new work steps, new categories, and new connectors to a 
workflow. 

J. Language 

20 A language component, along with locale and user components, gives a developer the 

ability to generate true international applications. These components enable developers to 
produce screen labels and help text assigned to specific users. Multiple users can run the 
same applications simultaneously, with different screen labels and help being displayed 
based not only on their language, but also on their specific locale. 

25 An example of a language data tab is shown in Figure 23(A). The language data tab 

includes a month names attribute for allowing a developer to represent long month names 
and a short month names attribute for allowing a developer to identify the short month 
names to be displayed. The language data tab also includes a day names attribute for 
allowing a developer to identify the long day-of-week names to be displayed and a short day 

30 names attribute for allowing a developer to identify the short day-of-week names to be 
displayed. An example of a language label tab is shown in Figure 23(B). The language 
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label tab provides developers with the capability to dynamically switch languages in menus. 

A locale component, as described above, along with the language and user 
components allow developers to produce screen labels based on user language and a specific 
user locale. An example of a local data tab is shown in Figure 24. The locale data tab 
5 includes a language attribute for allowing a developer to specify the language component to 
use in this locale. The locale data tab also includes attributes for allowing developers to 
define the character used to separate the decimal point, the character(s) to use to represent 
numeric and currency groups, the characters) to use to separate numeric date parts, the 
characters) to use to separate numeric time parts, an integer to define the number of digits in 
10 each group for non-currency numbers, and an integer to define the number of digits in each 
group for currencies. 

IV. Inheritance 

A. Overview 

15 Inheritance has already been described at least in part above with reference to some 

of the components. In general, multiple types of inheritance exist and the types of 
inheritance vary from each other according to the way in which they define relationships 
between components. Inheritance according to the invention differs in many ways from 
inheritance through existing object-oriented programming techniques. 

20 

B. Component/Attribute 

One type of inheritance is called component or attribute inheritance. Attribute 
inheritance defines a relationship between parent and child components where the child 

25 receives or inherits the property values of its parent. This relationship is defined through a 
component's parent property. A parent can have one or more child components but a child 
component can have only a single parent. An example of an attribute inheritance tree is 
shown in Figure 25(A). With reference to this Figure, components B, C, and D are childs of 
component A and each inherits the property values of component A. Further, components E 

30 and F are child components of component B and inherit those property values of component 
B. Similarly, component G is a child of component D. At any point in the hierarchy, 
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inherited property values can be overridden. When this happens, the inherited values of all 
affected child components are updated to reflect the change made at the parent level. Non- 
inherited or overridden property values are unaffected by changes made at its parent 
component. Thus, with reference again to Figure 25(A), all components below component A 
5 will inherit its property values. However, if a specific property value is overridden at 

component B, then components E and F will inherit that property value from component B 
but all other inherited values will continue to come from component A. 

In object-oriented programming, an object accesses another object's data by calling 
the object's data access methods. Thus, object-oriented programming discourages direct 
10 access to common data by other programs. Only the object that "owns" the data can change 
its content and other objects can view or change the data only by the owner. 

In contrast, inheritance with the invention allows components to inherit the data or 
attribute of its parent. With reference again to Figure 25(A), component E therefore would 
inherit the values or attributes of component B and component A. The values, however, may 
15 be overridden at component B so as to be different from those in component A. For these 
overridden values, components E and F will inherit the values of component B and not those 
of component A. Similarly, components E and F may override some of the values inherited 
from component B. 

The ability to inherit attributes or values from other components provides advantages 
20 over procedural programming techniques. For instance, an application may define a data 
element of the year and define its length to be two integers. Thus, the application may 
represent the year 1999 as "99." Typically, with a procedural program, the developer would 
have to first locate every line that contains the year and make an appropriate change to the 
code. With the invention, the developer need only go to the data element defining the year 
25 and change the length so that it is four digits rather than just two digits. This change is made 
within the repository and does not require any recompiling or debugging of the code. Thus, 
changes can be easily and quickly made to an application thereby reducing the cost to a 
company. 

30 C. Container 

In addition to attribute inheritance, the invention also supports container inheritance. 
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The transaction engine uses container inheritance to derive some values With container 

inheritance, a container may be defined to include a group of components. For example, 
with reference to Figure 25(B), a data element group for A/C History may contain data 
elements called Balance, Date and Transaction ID. At runtime, it is possible that all 

5 contained fields, with the exception of the Balance field, obtain their value from a common 
message store or message, such as one called Common, in accordance with the application 
logic. This common source for value may then only be specified with the immediate 
container of these fields, such as A/C History. The Balance field might refer to an altogether 
different source for its value at runtime. With reference to Figure 25(B), at runtime, the Date 

10 and Transaction ID fields inherit the Data Source attribute . which is that attribute which 
identifies the location/source of a field's value at runtime, from that of its container, namely 
A/C History. 



D. Language 

15 Many components contain multi-lingual attributes. These attributes contain a value 

for the attribute for each language supported by the application. Oftentimes, two languages 
for an attribute can share the same string value. For example, assume an application 
supports Canadian English, American English, and British English languages. If the 
application also creates a language called English and makes it the component parent of the 

20 other three more specific English languages, then whenever the three specific languages 
share a string value, the string value can be filled in the multi-lingual attribute for English 
and the transaction engine will use the English value as the value for any of the other three 
more specific languages that do not have a value. 

Figure 26 provides an illustration of language inheritance in one portion of the 

25 display. This portion of the display illustrates American English, Deutsch, and Espanol. 

Further divisions may be made within each language, such as European English, British, and 
Canadian English. Figure 26 also illustrates various data elements and the different 
languages. For instance, the data element telephone has a label "Telephone" in American 
English, Canadian English, and European English but has a label "Telefono" for Espanol. 

30 Similarly, a label named US_Dollars has a label "Currency" for the different versions of 
English but has a label as "Monedas" for Espanol. Thus, according to these examples, 
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Canadian English and European English inherit their values from American English but 
Espafiol has specified values, specifically "Telefono" and "Monedas ." 



E. Message 

5 In addition to attribute, container, and language inheritance, the invention also 

supports message inheritance. Occasionally, a message store may contain messages that are 
not in the same format, but the messages are part of a family of messages. Individual 
messages may provide some kind of type field that allows the application to decide how to 
parse each data element An example will now be described with reference to Figure 27. 

1 0 Four messages may be utilized to talk to an ATM machine. All the messages contained an 
account number and the second field describes what the message should do as well as the 
format for the rest of the message. For instance, when the transaction engine is presented 
with a "Withdrawal" message, the transaction engine will parse the message by first 
determining that the message store message type attribute is Root. The transaction will start 

15 by parsing in the data element of Root, which in this example will result in CaseAccount and 
Type. The transaction engine will evaluate the ParseSelector expressions of all children of 
Root and locate the true expression. In this example, the children of Root are Inquiry and 
Common and the selector will be true for Common. The transaction engine will next parse 
the data elements of Common and add "Amount" to the message. The transaction engine 

20 will evaluate the ParseSelector expressions of the children of Common and locate the 

selector of message with "Withdraw" as true. The transaction engine would then be finished 
parsing since "Withdraw" does not contain any child message types. 

F. Sibling 

25 The invention also supports sibling inheritance. As described above, a child 

component can inherit all attributes or values of its parent component. The child component, 
however, need not inherit all values and some may be overwritten. Another way in which a 
child component can inherit from another component is through sibling inheritance. With 
sibling inheritance, a value in one component is expressed relative to a value in another 

30 component. For instance, a first component may have a value that is expressed as two times 
the value defined in a second component. Other siblings may be added to an existing sibling 
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relationship, such as by specifying that a third component has a value defined relative to the 
value in the first component which, in turn, is tied to the value in the second component. 



G. Value-Based Inheritance 

System users can also benefit from inheritance. An Account Master file, for example, 
could have records organized as an arbitrarily large hierarchy, perhaps corresponding to the 
organizational structures of various organizations. An agent could set a field value, such as a 
spending limit, in a record corresponding to a particular organizational level and have it 
apply to all the people in that organization. The ability to override inherited values would let 
the agent override that spending limit for any particular group within that organization. 

H. Component Replacement Inheritance 

Component Replacement Inheritance (CRI) is similar in some ways to normal 
attribute inheritance. With CRI, however, if a component A' is made to inherit from A, A' 
will be treated the same as A. As a result, other components or other aspects of an 
application that refer to A would then use the modified A'. CRI can also chain components 
together. For instance, a string of components could be defined as A <- A' <- A" «— A'". 
With this type of inheritance, A could represent an application delivered by the developer, A' 
the customization performed by a multi-national company, A" the customization performed 
by some national part of the company, and A"' the customization performed by a division 
within that particular country. 

CRI provides many advantages, especially with respect to customization and 
maintenance. From the developer's viewpoint, the developer can deliver an application and 
can allow the customer to customize it by using CRI. Rather than needing to modify the 
application itself, the customer can advantageously use CRI to inherit from the pieces they 
want to modify. The system treats the modifications as if they occurred within the 
application itself, but the modifications are isolated in separate files. 

V. User Interface 

The systems and methods according to the invention allow interfaces to be easily 
developed. For instance, a data group component D may be defined to include data element 
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components A, B, and C. A data group is not limited to a collection of individual 
components but may also be defined to include other data groups. For instance, a data group 
component F may be defined to include the data group component D as well as a data 
element component E. 

5 The use of these data elements and data element groups allows a developer to easily 

define a panel on a screen. An explanation will now be provided with reference to the 
development of a panel shown in Figure 28. This panel includes data elements 1 DEI and 2 
DE 2 that are defined within a panel labeled Group 1. The Group 1 panel also includes a 
component labeled Button 6. The Group 1 panel forms a part of a larger group labeled Panel 

10 1 . The Panel 1 container, in addition to the Group 1 panel, is defined to include additional 
components labeled Button 1 to Button 5. 

An example of a table listing the positions of each element in Group 1 is shown in 
Figure 29. As shown in this Figure, data element DE 1 is positioned at the top left of the 
panel, data element DE 2 is positioned relative to data element DE 1 in a vertical direction, 

15 and Button 6 is positioned at the bottom right of the panel. An advantage of such a 

positioning scheme is that it allows the data element DE 2 to be always positioned below the 
first data element DE 1 . Thus, the second data element DE 2 will dynamically reposition 
itself within the screen if a change in data element 1 DE 1 affects the amount of vertical 
space consumed by that data element. 

20 Figure 30 is a table that illustrates the relative positioning of the components forming 

the Panel 1 group. As reflected in this table, the Group 1 panel is at the top left of the 
display, the first button Button 1 is at the top right, and the third button Button 3 is at the 
bottom left. Thus, the Group 1 panel and the first and third buttons are at a fixed position on 
the screen. The second, fourth, and fifth buttons, on the other hand, are positioned relative to 

25 other components. The second button Button 2 is positioned relative to the first button 

Button 1 in a vertical direction, the fourth button Button 4 is positioned relative to the third 
button Button 3 in a horizontal direction, and the fifth button Button 5 is positioned relative 
to the fourth button Button 4 in a horizontal direction. Thus, Button 2 will always be below 
Button 1, Button 4 will always be to the right of Button 3, and Button 5 will always be to the 

30 right of Button 4. 

Another illustration of building panels will be provided with reference to Figures 
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3 1 (A) to 3 1 (C). Figure 3 1 (A) illustrates a panel labeled "My Test Panel" which may be 
formed from one data element component. In creating this panel, the data element 
component may be defined to have a length of 40, a view of entry, a label equal to "Name," 
and label positioning equal to top. The data element for the label name can then be added to 
5 a data element group called "My Panel." The data element group called "My Panel" can 
have a type defined as group, a view defined as panel, and a label defined as "My Test 
Panel." This data element group would then contain the data element for "Name" as one of 
its children. 

The developer may then add "City" and "State" to the panel, as shown in Figure 
10 31(B). To form the panel shown in Figure 31(B), a developer can add a second data element 
component for the city and define the view as entry, the length as 25, the label as "City:", the 
label position as top and the position as relative to the name data element. The state data 
element component can also be added to the panel group and can be defined to have a view 
as ComboBox, label as "State:", label position as top, and position as relative to the city data 
1 5 element component. 

In a similar way, additional components or groups of components may be added to 
the panel. For instance, as shown in Figure 31(C), a set of buttons labeled as "Print," "OK," 
and "Cancel" have been added to the group labeled "My Test Panel." The Print, OK, and 
Cancel buttons can therefore be defined as separate data elements and as a command button 
20 and can be included within a data element group that is included within the group for the test 
panel. 

An explanation will now be provided with reference to a payment processing system 
to illustrate some advantages of the invention. Figure 32 illustrates an interface that may be 
presented to a user, such as a client representative. The interface shown presents information 

25 on a particular card-holder's account, such as the card-holder's name, address, list of 
transactions, balance and interest information, and a set of control buttons. 

Figure 33 illustrates a data element group that defines the interface shown in Figure 
32. The data element group entitled DemoGroup contains elements of a NameBlock group 
component. AddressBlock group component, Transaction group component, Balance 

30 component, Interest component, and RSMFormControls group component. The NameBlock 
group defines the top two rows of the display, the AddressBlock group defines the address 
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information, the Transaction group defines the list of transactions, the Balance element 
defines the balance, the Interest element defines the interest, and the RSMFormControl 
group defines the buttons on the bottom of the display. As shown in more detail in Figure 
34, the NameBlock data element group includes individual data elements for account 
number AcctNum, statement date StmtDate, name Name, personal identification number 
PIN, credit limit CreditLimit, late payment LatePayment, and VIP status of the card-holder 
VIP. 

All of the data elements and data element groups have their positions defined on the 
interface shown in Figure 32. For instance, looking at the CreditLimit data element shown 
in Figure 35, the credit limit information is displayed relative to the statement date in a 
vertical direction. With reference to Figure 32, the credit limit is shown below the payment 
due date. The position of the StmtDate data element as shown in Figure 36 is defined 
relative to the PIN data element in a horizontal direction. Thus, as shown in Figure 32, the 
payment due date field is positioned horizontally to the right of the PIN field. The message 
store component conveniently allows developers and users to designate the data type. Figure 
37 provides an example of a message store component for account balance and illustrates 
examples of storage types available. These storage types include, but not be limited to 
DBMS, FlatFile, Inmemory, Queue, Logical, Network, VSAM, HLLAPI, and DSL. 

As described above, interfaces developed with this invention allow for security to be 
assigned based on the user. As an example, Figure 38(A) illustrates account information that 
may be available to a first user having a greater degree of permission than a second user, 
which receives the account information shown in Figure 38(B). Advantageously, fields that 
are omitted when displaying the information to the second user, namely the Open-to-buy and 
Credit limit information is not shown in the interface displayed in Figure 38(B). 
Furthermore, the interface is dynamically altered so that the Total accounts information is 
displayed immediately below the Amount due data. In other words, the interface shown in 
Figure 38(B) does not include a space between the Total accounts and the Amount due for 
the omitted Open-to-buy and Credit limit fields. The interface as shown in Figure 38(B) 
therefore provides no suggestion to the second user that information has been concealed. 

Another benefit of the invention is that the interfaces can be dynamically changed 
according to the language displayed. An illustration of this ability will now be described 
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with references to Figures 39(A) and 39(B). Figure 39(A) illustrates a portion of an 
interface displayed in an English language and depicts a Transaction field above a Short 
Name field, an Organization field to the right of the Transaction field, a Logo field to the 
right of the Organization field, and a Status field below the Logo field. As is apparent from 
5 Figure 39(B), the relationships between these fields remain the same even when the interface 
is displayed in another language. Thus, when the interface is changed to Spanish, 
Transacci6n is still above the Nombre Corto field, the Organizacion is still to the right of 
Transacci6n, the Logo is still to the right of Organizacion, and Estatus is still below the Logo 
field. The resizing of the interface is also apparent from the tabs. 

10 

VI. Scalability and Other Benefits 

The systems and methods according to the invention define a platform that presents 
an environment specially tailored to efficiently support financial programming. Typical 
financial programs repeatedly use the same types of constructs, such as varying descriptions 

15 of account numbers or embedded SQL calls to a database. By applying object-oriented 
programming principles to abstract these common constructs into platform objects, the 
invention provides a mechanism to reduce the size and scope of the non-common, 
application-specific software and thereby reduce maintenance costs. 

In addition to object-oriented techniques, the invention employs a non-procedural 

20 programming style. With the invention, developers declare what the application should do, 
as opposed to the more traditional development model where the developer creates a 
program that tells how to realize an application. To support this non-procedural or 
declarative method of programming, the invention provides a relatively small number of 
components and component properties, also called attributes, that an application developer 

25 can define. The platform according to the invention understands how a component should 
behave based on what the application developer has defined the attributes. The declarative 
approach provides a way to push common programming into the platform, reduce the size of 
the application-specific portion, and reduce the associated maintenance costs. 

The platform according to the invention is declarative and object-oriented in nature. 

30 The platform is built not only using an object-oriented language, such as C++, but makes 
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objects the basis for the platform environment itself. A significant advantage achieved from 
this approach is to make systems built using this platform easier to extend and maintain. 

The invention also presents advantages in inheritance. In general, inheritance 
provides the ability to define a hierarchy such that objects lower in the hierarchy can 
automatically "inherit" values associated with objects above them. A main advantage of 
inheritance is the ability to make a change in a single place that should apply to a collection 
of objects. For instance, one can define a base AccountNumber data element and have all 
Account Number definitions inherit from that base. Assume that all account numbers start 
out being a maximum of 15 digits long, and one encodes this information in the base 
AccountNumber definition. If there is a subsequent need to expand the maximum length of 
account numbers to 21, one need only make the change in one place and have it apply to all 
my account numbers. Similarly, if a set of related Message Stores inherits from a base 
Message Store definition that initially associates the store with the Microsoft SQL Server 
RDBMS, changing the base definition to use Oracle will make all inheriting definitions use 
Oracle. 

With procedural programming, the computer knows how to do a small number of 
very basic commands, such as assignment, branching, and arithmetic. The developer uses 
the commands to tell the computer how to perform a task. General purpose programming 
languages support procedural programming. 

Application-oriented programming languages embody application-specific 
knowledge into a set of higher-level programming constructs. Application in this sense may 
be application areas, such as financial transactions or word processing. Application-oriented 
languages may be procedural or declarative; they are declarative if the way they provide 
access to their higher-level constructs is via interpreting attributes. 

Declarative programming can reduce the number of places in a program where a 
developer needs to make changes. For example, authorization systems keep counts on 
account activity, such as a daily tally of approved transactions for each account. In a 
procedural authorization system, there would be n places in that program where it could 
decide to approve a transaction. To keep the tally, the developer would tell the system in 
each of those n places to look up the appropriate data element and increment it. 
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On the other hand, a declarative approach would take advantage of the fact that no 
matter what the value of the tally is at any given time, it is always the current count of 
approved transactions. So the developer could declare that definition to be an attribute of the 
tally data element itself. According to the invention, the tally would be a derived data type. 
5 The developer can take advantage of the fact that the platform according to the invention 
knows how to take counts of records that exist in message stores (optionally partitioned by 
account and approved/declined). 

The declarative approach breaks the direct tie in the code between approving a 
transaction and updating data elements that care whether it was approved. From a 

10 maintenance point of view, if the definition of the tally data element needs to be changed, a 
change need only be made at the data element itself whereas with procedural applications the 
n places in the code that contain the definition would first have to be located and then those 
lines of code would have to be changed. 

With the platform according to the invention, applications are collections of 

1 5 workflows and each workflow is a set of interconnected worksteps. Information flows 
among worksteps as messages. Each workstep is an independent processing unit in that it 
performs a function driven entirely by its input message(s). A single process could schedule 
and run the entire application, but the message passing and independent nature of the 
worksteps provides scalability. 

20 An application can run subsets of workflows as different threads or processes or on 

different processors. In fact, each workstep could run on a separate processor. In addition, 
since each processor would essentially be a server taking work from its message-based in 
box, the same workstep could be assigned to multiple processors so that work destined for a 
particular workstep could be served by any of the n processors running that workstep. 

25 Ultimately, a set of n available processors may be provided, any one of which could 

run any workstep that had available work as soon as it became free. Limits, however, could 
be placed on which worksteps a particular processor would be eligible to run. When a user 
interacts with the system, for instance, that user's workstation could be the only server 
eligible to execute the corresponding interactive worksteps. 

30 The forgoing description of the preferred embodiments of the invention has been 

presented only for the purpose of illustration and description and is not intended to be 
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exhaustive or to limit the invention to the precise forms disclosed. Many modifications and 
variations are possible in light of the above teaching. 

The embodiments were chosen and described in order to explain the principles of the 
invention and their practical application so as to enable others skilled in the art to utilize the 
5 invention and various embodiments and with various modifications as are suited to the 
particular use contemplated. 
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CLAIMS 

What we claim: 



1 1 . A system for use in managing accounts, comprising: 

2 a repository for storing definitions of components, for storing definitions of message 

3 types, for storing definitions of worksteps, and for storing a definition of a workflow; 

4 the components include data elements wherein attributes of each data element is 

5 stored in the repository; 

6 each of the message types comprising a set of data elements; 

7 each workstep defining a unit of work for being performed by the system wherein 

8 multiple worksteps define the workflow for processing account information; and 

9 a transaction engine for passing messages between worksteps according to the 
10 workflow. 

1 2. The system as set forth in claim 1 , wherein the data elements include attributes 

2 for defining a display of information associated with the data elements. 

1 3. The system as set forth in claim 2, wherein the attributes define a position of 

2 the information within the display. 

1 4. The system as set forth in claim 3, wherein the attributes define a position of 

2 the information relative to the display. 

1 5. The system as set forth in claim 3, wherein the attributes define a position of 

2 the information relative to information associated with at least one other data element. 

1 6. The system as set forth in claim 1 , wherein the attributes define security 

2 associated with the data element. 

1 7. The system as set forth in claim 1 , wherein the components include language 

2 components for defining a plurality of languages that may be used in an interface to a user. 
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1 8. The system as set forth in claim 1 , wherein the components include a locale 

2 component for defining a plurality of locales that may be used in an interface to a user. 

1 9. The system as set forth in claim 1, wherein me repository includes definitions 

2 for a join component, the join component defining a relationship between data elements. 

1 1 0. The system as set forth in claim 1 , wherein the repository includes definitions 

2 for a restriction component, the restriction component defining limitations on values of at 

3 least one data element. 

1 11. The system as set forth in claim 1 , wherein the repository includes definitions 

2 for an expression component. 

1 12. The system as set forth in claim 1 , wherein the repository includes definitions 

2 for a user component, the user component identifying attributes of at least one user. 

1 13. The system as set forth in claim 1 , wherein the repository includes a definition 

2 for a message store, the message store specifying a storage type for data associated with at 

3 least one of the data elements. 

1 14. The system as set forth in claim 1 3 , wherein the message store includes 

2 definitions for file format. 

1 1 5. The system as set forth in claim 13, wherein the storage type includes network 

2 storage and the message store includes definitions for transport type. 



1 



1 6. The system as set forth in claim 1 , wherein the repository includes definitions 

2 for a query component, the query component defining an interaction with data associated 

3 with at least one data element. 



1 7. The system as set forth in claim 1 , wherein the repository includes definitions 
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for connectors, the connectors linking the worksteps to form the workflow. 



1 18. The system as set forth in claim 1, wherein the transaction engine is for 

2 prioritizing the messages. 

1 19. The system as set forth in claim 1, wherein the transaction engine is for 

2 scheduling the messages. 

1 20. The system as set forth in claim 1 , further including an interface for use in 

2 altering the definitions stored in the repository. 

1 2 1 . A user interface for use with a computer system, comprising: 

2 a repository for storing definitions of components, wherein each component has at 

3 least one attribute related to a representation of information associated with the component 

4 to a user; and 

5 a transaction engine for representing the information to the user in accordance with 

6 the at least one attribute for the component. 

1 22. The user interface as set forth in claim 2 1 , wherein the at least one attribute is 

2 a position of the information on a display. 



1 23. The user interface as set forth in claim 22, wherein the at least one attribute 

2 defines a position of the information relative to the display. 

1 24. The user interface as set forth in claim 22, wherein the at least one attribute 

2 defines the position of the information relative to information associated with another 

3 component. 

1 25. The user interface as set forth in claim 2 1 , wherein the attribute defines 

2 security restrictions of the user to the information. 
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1 26. The user interface as set forth in claim 2 1 , wherein the attribute defines one of 

2 a plurality of languages and the transaction engine presents the information to the user in a 

3 designated language. 

1 27. The user interface as set forth in claim 2 1 , wherein the attribute defines one of 

2 a plurality of locales and the transaction engine presents the information to the user in a 

3 format particular to a designated locale. 

1 28. The user interface as set forth in claim 2 1 , further comprising an interface for 

2 allowing a user to alter the definitions stored in the repository. 

1 29. The user interface as set forth in claim 2 1 , wherein the information is account 

2 information. 



1 30. A user interface for use with a processing system and for displaying account 

2 information, the user interface comprising: 

3 a display for displaying account information; 

4 a repository for storing data defining a manner in which the account information is to 

5 be displayed; 

6 an engine for receiving the account information and for displaying the account 

7 information at the display in accordance with the data stored in the repository; and 

8 an interface for enabling a user to alter the data stored in the repository; 

9 wherein changes to the data stored in the repository result in a change in the manner 
10 in which account information is displayed. 

1 31. The user interface as set forth in claim 30, wherein the data stored in the 

2 repository includes a language in which the account information is displayed. 

1 32. The user interface as set forth in claim 30, wherein the data stored in the 

2 repository includes a locale in which the account information is displayed. 
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1 33. The user interface as set forth in claim 30, wherein the data stored in the 

2 repository controls security rights to the account information. 

1 34. The user interface as set forth in claim 30, wherein the data stored in the 

2 repository defines groups of users. 

1 35. The user interface as set forth in claim 30, wherein the engine is for receiving 

2 legacy data. 

1 36. The user interface as set forth in claim 30, wherein the engine is for displaying 

2 legacy data in a tabular format. 

1 37. The user interface as set forth in claim 30, wherein the data stored in the 

2 repository includes join information for use in defining links to allow a user to navigate 

3 through the user interface. 

1 38. The user interface as set forth in claim 30, wherein the data stored in the 

2 repository includes expression information for use in selectively displaying items on the 

3 display. 

1 39. The user interface as set forth in claim 38, wherein the expression information 

2 is for use in selectively displaying menu items. 

1 40. The user interface as set forth in claim 38, wherein the expression information 

2 is for use in selectively displaying buttons. 

1 41 . The user interface as set forth in claim 38, wherein the expression information 

2 is for use in selectively displaying fields. 



1 

2 



42. The user interface as set forth in claim 30, wherein the data stored in the 
repository includes query information for use in building explorer views. 
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